Smart contract of a blockchain for management of cryptocurrencies

ABSTRACT

There is provided a processor(s) executing a blockchain smart contract, for: managing a primary reserve of primary tokens and a secondary reserve of secondary tokens, receiving a transaction request, obtaining an external price of the primary token, compute an updated value of the primary reserve according to the external price, in response to the updated total value of primary reserve being unequal to an initial staked value of the primary reserve, adjust primary and secondary dynamic reserve weights, wherein a total value computed by a function of the primary reserve after being increased or decreased by a target amount of primary tokens and using the adjusted primary and secondary dynamic reserve weights, is equal to the initial staked value of the primary reserve, and the total value of the primary reserve is maintained at a predefined ratio to a total value of the secondary reserve, and executing the transaction request.

FIELD AND BACKGROUND OF THE INVENTION

The present invention, in some embodiments thereof, relates tocybersecurity and, more specifically, but not exclusively, to systemsand methods for cybersecurity for smart contracts of blockchainperforming cryptocurrency.

Advances in blockchain technology provide distributed (i.e.,non-centralized approaches) to enable almost any entity to create theirown custom cryptocurrencies and/or create their own smart contract thatprovides cryptocurrency exchange services, thereby creating a targetprone to cyberattack and/or malicious activities. Cybersecurityapproaches are being developed to protect such smart contracts frommalicious activities and/or cyberattack.

SUMMARY OF THE INVENTION

According to a first aspect, a computing device for cybersecurity of adistributed smart contract executing on a blockchain, comprising: atleast one hardware processor of a network connected server executing acode of the distributed smart contract of a distributed ledger dataset,the code for: managing a primary reserve of a plurality of primarytokens of a primary cryptocurrency and a secondary reserve of aplurality of secondary tokens of a secondary cryptocurrency, receiving atransaction request for the primary token, accessing a price oracle toobtain an external price of the primary token, computing an updatedtotal value of the primary reserve according to the external priceprovide by the price oracle, in response to the updated total value ofprimary reserve computed based on the price oracle being unequal to aninitial staked value of the primary reserve, adjust a primary dynamicreserve weight and adjust a secondary dynamic reserve weight, wherein atotal value computed by a function of the primary reserve after beingincreased or decreased by a target amount of primary tokens and usingthe adjusted primary and secondary dynamic reserve weights, is equal tothe initial staked value of the primary reserve, and the total value ofthe primary reserve is maintained at a predefined ratio to a total valueof the secondary reserve, and executing the transaction request.

According to a second aspect, a method of cybersecurity of a distributedsmart contract executing on a blockchain using at least one hardwareprocessor of a network connected server executing a code of thedistributed smart contract of a distributed ledger dataset, for:managing a primary reserve of a plurality of primary tokens of a primarycryptocurrency and a secondary reserve of a plurality of secondarytokens of a secondary cryptocurrency, receiving a transaction requestfor the primary token, accessing a price oracle to obtain an externalprice of the primary token, computing an updated total value of theprimary reserve according to the external price provide by the priceoracle, in response to the updated total value of primary reservecomputed based on the price oracle being unequal to an initial stakedvalue of the primary reserve, adjust a primary dynamic reserve weightand adjust a secondary dynamic reserve weight, wherein a total valuecomputed by a function of the primary reserve after being increased ordecreased by a target amount of primary tokens and using the adjustedprimary and secondary dynamic reserve weights, is equal to the initialstaked value of the primary reserve, and the total value of the primaryreserve is maintained at a predefined ratio to a total value of thesecondary reserve, and executing the transaction request.

According to a third aspect, a computer program product forcybersecurity of a distributed smart contract executing on a blockchain,comprises: a non-transitory memory storing thereon code for execution byat least one hardware process, the code including instructions for:managing a primary reserve of a plurality of primary tokens of a primarycryptocurrency and a secondary reserve of a plurality of secondarytokens of a secondary cryptocurrency, receiving a transaction requestfor the primary token, accessing a price oracle to obtain an externalprice of the primary token, computing an updated total value of theprimary reserve according to the external price provide by the priceoracle, in response to the updated total value of primary reservecomputed based on the price oracle being unequal to an initial stakedvalue of the primary reserve, adjust a primary dynamic reserve weightand adjust a secondary dynamic reserve weight, wherein a total valuecomputed by a function of the primary reserve after being increased ordecreased by a target amount of primary tokens and using the adjustedprimary and secondary dynamic reserve weights, is equal to the initialstaked value of the primary reserve, and the total value of the primaryreserve is maintained at a predefined ratio to a total value of thesecondary reserve, and executing the transaction request.

In a further implementation form of the first, second, and thirdaspects, a primary dynamic reserve weight is computed using theparameters of: a total amount of primary tokens in the primary reserve,a total amount of previously staked primary tokens in the primaryreserve, a total amount of secondary tokens in the secondary reserve,the external price of the primary token, and an external price of thesecondary token, wherein a secondary dynamic reserve weight is computedby subtracting the primary dynamic reserve weight from 1, wherein acurrent value of the respective primary and secondary token as offeredby the smart contract is automatically computed by the function usingthe amount of the respective primary and secondary token in therespective primary and secondary reserve, amount of respective primaryand secondary token in circulation, and the respective primary andsecondary dynamic reserve weight.

In a further implementation form of the first, second, and thirdaspects, a current price of the primary token computed by the functionusing the adjusted weight and the primary reserve, prior to beingincreased or decreased by the target amount of primary token, isdifferent than the external price of the primary token provided by theprice oracle.

In a further implementation form of the first, second, and thirdaspects, after execution of another transaction request for the targetamount of primary token corresponding to the increase or decrease of theprimary token, a current price of the primary token computed by thefunction using the adjusted weight and the primary reserve after beingincreased or decreased by the target amount, is equal to the externalprice of the primary token provided by the price oracle.

In a further implementation form of the first, second, and thirdaspects, after execution of another transaction request for the targetamount of primary token corresponding to the increase or decrease of theprimary token, the total value of the primary reserve computed by thefunction using the adjusted weight and amount of the primary tokensstored in the primary reserve after being increased or decreased by thetarget amount, is equal to the initial staked value of the primaryreserve.

In a further implementation form of the first, second, and thirdaspects, the target amount comprises the target amount of primary tokensthat are converted into the secondary token such that the predefinedratio of the price of the primary token relative to the price of thesecondary token computed by the function after the execution of theanother transaction request, becomes equal to the ratio of the price ofthe primary token relative to the price of the secondary token obtainedfrom the price oracle.

In a further implementation form of the first, second, and thirdaspects, further comprising: in response to the updated total value ofthe primary reserve computed based on the price oracle being equal tothe initial staked value of the primary reserve, adjusting eachrespective dynamic reserve weight to respective adjusted weights,wherein a total value of the primary reserve computed by the functionusing the respective adjusted weights, is equal to the initial stakedvalue of the primary reserve, and the total value of the primary reserveis maintained at a predefined ratio to a total value of the secondaryreserve.

In a further implementation form of the first, second, and thirdaspects, the primary dynamic reserve weight and the secondary dynamicreserve weight are computed using a Lambert W function.

In a further implementation form of the first, second, and thirdaspects, the primary dynamic reserve weight of the primary token isdenoted as 1/(1+x), and the secondary dynamic reserve weight of thesecondary token is denoted as x/(1+x), wherein:

$x = {\frac{T}{b\; p} \cdot {\sum\limits_{n = 1}^{\infty}\;{\frac{n^{n - 1}}{n!} \cdot \left( \frac{T\mspace{11mu}\log\mspace{11mu}\left( \frac{T}{t} \right)}{b\; p} \right)^{n - 1}}}}$

T=primary token reserve staked balance,b=secondary token reserve current balance,p=ratio of primary token/secondary token off-chain price as provided bythe price oracle,t=secondary token reserve current balance as computed by the function.

In a further implementation form of the first, second, and thirdaspects, further comprising virtually amplifying the amount ofrespective primary and secondary tokens in the reserves, wherein thefunction is computed using the virtually amplified amount.

In a further implementation form of the first, second, and thirdaspects, wherein the virtually amplified amount of each respective tokenis computed by multiplying the initial staked value of the respectivetoken by an amplification value and subtracting therefrom, a differencebetween the initial staked value of the respective token and the currentbalance of the respective token in the reserves.

In a further implementation form of the first, second, and thirdaspects, wherein the transaction request comprises one of: convertingthe primary token into the secondary token, and converting the secondarytoken into the primary token, wherein the transaction request isexecuted after the adjustment of each respective dynamic weight to theadjusted weight.

In a further implementation form of the first, second, and thirdaspects, wherein the transaction request comprises adding a depositamount of a certain token to the reserves, wherein the transactionrequest is executed prior to the accessing the price, computing to theupdated value, and to the adjust each respective dynamic value, andfurther comprising code for minting an amount of a certain pool tokencorresponding to the deposit amount of the certain token, wherein thevalue of the deposit amount of the certain token is computed using thefunction prior to the execution of the transaction request, wherein thecertain token is the primary token or the secondary token, and thecertain pool token is a primary pool token corresponding to the primarytoken or a secondary pool token corresponding to the secondary token.

In a further implementation form of the first, second, and thirdaspects, the transaction requests comprises adding 100% of the depositamount to the certain token, and wherein the amount of the certain pooltoken corresponds to 100% of the deposit amount of the certain token.

In a further implementation form of the first, second, and thirdaspects, the transaction request comprises adding a selected percentagedeposit amount of a primary token and another selected percentagedeposit amount of the secondary token to the reserves, wherein thetransaction request is executed prior to the accessing the price,computing to the updated value, and to the adjust each respectivedynamic value, and wherein minting comprising minting a primary amountof the primary pool token corresponding to the deposit amount of theprimary token, and minting a secondary amount of the secondary pooltoken corresponding to the deposit amount of the secondary token,wherein the value of the primary and secondary deposit amounts iscomputed using the function prior to the execution of the transactionrequest.

In a further implementation form of the first, second, and thirdaspects, a value of the certain pool token is constant before and afterthe transaction request is executed, wherein a ratio between a totalvalue of the total amount of certain pool tokens and the initial stakedvalue of the certain token remains constant.

In a further implementation form of the first, second, and thirdaspects, further comprising code for: extracting a fee in response toexecuting a conversion of the certain token, adding the fee to theinitial staked value of the certain token and/or the converted token,wherein the value of the certain pool token corresponding to the certaintoken is increased by the corresponding increase in the initial stakedvalue of the certain token.

In a further implementation form of the first, second, and thirdaspects, extracting the fee comprises extracting a dynamic fee, whereinthe dynamic fee is reduced relative to a baseline fee when the totalvalue of the secondary reserve computed using an external price of thesecondary token is greater than the initial staked value of thesecondary reserve, and the dynamic fee is increased relative to thebaseline fee when the total value of the secondary reserve is less thanthe initial staked value of the secondary reserve, wherein the fee addedto the initial staked value is computed based on the baseline fee.

In a further implementation form of the first, second, and thirdaspects, extracting the fee comprises extracting a dynamic fee, whereinthe dynamic fee is computed when the conversion is from a primary tokento a secondary token, wherein the dynamic fee is computed as: dynamicfee=baseline fee*secondary ratio, secondary ratio=staked amount ofsecondary tokens in the secondary reserve/total amount of secondarytokens in the secondary reserve, wherein the fee added to the initialstaked value is computed based on the baseline fee.

In a further implementation form of the first, second, and thirdaspects, the transaction request comprises receiving an amount ofcertain pool tokens for withdrawal, and further comprising: computing awithdrawal value of the certain token corresponding to the amount ofcertain pool tokens for withdrawal using the function prior to executionof the transaction request, destroying the amount of certain pool tokensfor withdrawal, executing the transaction by removing the withdrawalvalue of the certain token from the reserves, wherein the transactionrequest is executed prior to the accessing the price, to computing theupdated value, and to adjust each respective dynamic value.

In a further implementation form of the first, second, and thirdaspects, further comprising code for: detecting a failure of the priceoracle in providing the external price of the primary token, whereinexecuting the transaction request comprises executing the transactionrequest using the function and dynamic reserve weights prior to thefailure of the price oracle, detecting restoration of the price oraclein providing the external price of the primary token, and in response tothe updated total value of primary token computed based on the restoredprice oracle and stored in the reserves being unequal to the initialstaked value of the primary token, adjust each respective dynamic weightto an adjusted weight, wherein a total value computed by the functionusing the adjusted weight, of the primary tokens stored in the reserveafter being increased or decreased by a target amount of primary tokens,is equal to the initial staked value.

Unless otherwise defined, all technical and/or scientific terms usedherein have the same meaning as commonly understood by one of ordinaryskill in the art to which the invention pertains. Although methods andmaterials similar or equivalent to those described herein can be used inthe practice or testing of embodiments of the invention, exemplarymethods and/or materials are described below. In case of conflict, thepatent specification, including definitions, will control. In addition,the materials, methods, and examples are illustrative only and are notintended to be necessarily limiting.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Some embodiments of the invention are herein described, by way ofexample only, with reference to the accompanying drawings. With specificreference now to the drawings in detail, it is stressed that theparticulars shown are by way of example and for purposes of illustrativediscussion of embodiments of the invention. In this regard, thedescription taken with the drawings makes apparent to those skilled inthe art how embodiments of the invention may be practiced.

In the drawings:

FIG. 1 is a block diagram of components of a system for executingtransactions of cryptocurrencies based on dynamically adjusted dynamicreserve weights for providing cybersecurity of a smart contact, inaccordance with some embodiments of the present invention;

FIG. 2 is a flowchart of an exemplary process of executing transactionsof cryptocurrencies based on dynamically adjusted dynamic reserveweights for providing cybersecurity of a smart contact, in accordancewith some embodiments of the present invention;

FIG. 3 is a flowchart of an exemplary process of depositing a selectedpercentage of a primary token and/or a selected percentage of asecondary token into the corresponding token reserve, in accordance withsome embodiments of the present invention; and

FIG. 4 is a flowchart of an exemplary process of withdrawing a selectedamount of a primary token and/or a selected amount of a secondary tokenfrom the corresponding token reserve, in accordance with someembodiments of the present invention.

DESCRIPTION OF SPECIFIC EMBODIMENTS OF THE INVENTION

The present invention, in some embodiments thereof, relates toblockchain based cryptocurrencies and, more specifically, but notexclusively, to systems and methods for distributed transactions ofblockchain based cryptocurrencies.

As used herein, the term cryptocurrency and token are interchangeable. Atoken may be created for different purposes and/or uses, for example,representing money, club member points, frequent flyer points, rewardpoints, as part of a game, and the like. Tokens may be customizedcryptocurrencies issued and based upon another cryptocurrency such asprovided by the Ethereum Network, Lisk, RootStock, and other Networks.

As used herein, the terms amount, value, and balance may sometimes beinterchanged, for example, referring to the total amount and/or valueand/or balance of a certain token reserve. The term amount may refer tothe number of tokens.

As used herein, the term staked refers to the amount and/or value oftokens that is added to one or both of the reserves. The term initialstaked refers to the initial amount and/or value of tokens provided toset-up the reserves. Additional amounts and/or value of tokens depositedto the existing reserves may also be referred to herein as staked, incontrast to the current value and/or amount of tokens that is already inthe respective reserve(s). The term previously staked may refer to thetotal staked amount, including the initial staked amount and subsequentadditional deposits. The current value and/or amount of tokens includesthe initially staked amount, additional amounts deposited into thereserves (e.g., previously staked), and/or tokens that were added to thereserves as part of a cryptocurrency transaction between the tworeserves.

It is noted that the terms primary and secondary used herein arearbitrarily, as any one of the two tokens and/or reserves and/or dynamicweights and/or pool tokens may be referred to as primary, with the otherreferred to as secondary. The terms primary and secondary are used forconvention and clarity of explanation.

An aspect of some embodiments of the present invention relate tosystems, methods, an apparatus, and/or code instructions (stored in amemory and executable by one or more hardware processors) for executinga smart contract of a blockchain that executes cryptocurrencytransactions (e.g., deposit, withdrawal, conversion) using a primaryreserve of primary tokens of a primary cryptocurrency and a secondaryreserve of secondary tokens of a secondary cryptocurrency, based ondynamically computed adjustments to a primary dynamic reserve weightand/or a secondary dynamic reserve weight, optionally for providingcybersecurity for the smart contact and/or otherwise protecting tokenand/or cryptocurrency reserves from losses (e.g., which may occur duringstandard operation of the smart contact and/or due to malicious actsand/or cyberattacks). The primary dynamic reserve weight is computedusing the following parameters: a total amount of primary tokens in theprimary reserve, a total amount of primary tokens staked (e.g.,initially staked) in the primary reserve, a total amount of secondarytokens in the secondary reserve, external (i.e., off-chain, not computedby the smart contract) price of the primary token (e.g., obtained from aprice oracle), external (i.e., off-chain, not computed by the smartcontract) price of the secondary token (e.g., obtained from a priceoracle). The secondary dynamic reserve weight is computed using thevalue computed for the primary dynamic reserve weight, by subtractingthe primary dynamic reserve weight from one (1). A current value of therespective primary and secondary token, as offered by the smart contract(which may be different than the corresponding external price) isautomatically computed by a function of the amount of the respectiveprimary and secondary token in the respective primary and secondaryreserve, amount of respective primary and secondary token incirculation, and the respective primary and secondary dynamic reserveweight (which is dynamically adapted as described herein). When atransaction request for conversion of an amount of the primary tokeninto the secondary token (or for conversion of the secondary token intothe primary token) is received by the smart contract (e.g., from aclient terminal), a price oracle (e.g., server) is accessed to obtain anexternal (optionally real time) price of the primary and/or secondarytoken. An updated total value of the primary reserve and/or secondaryreserve is computed according to the corresponding external price. Inresponse to the updated total value of primary reserve being unequal toan initial staked value of the primary reserve and/or the updated totalvalue of the secondary reserve being unequal to an initial staked valueof the secondary reserve, the primary dynamic reserve weight is adjustedto a primary adjusted dynamic reserve weight, and/or the secondarydynamic reserve weight is adjusted to a secondary adjusted dynamicreserve weight. The adjustment is performed to select the primaryadjusted dynamic reserve weight and/or the secondary adjusted dynamicreserve weights that when used by the function to compute the price ofthe primary tokens stored in the primary reserve after the primaryreserve is increased or decreased by a target amount of primary tokens,is equal to the initial staked value of the primary reserve, and so thatthe total value of the primary reserve is maintained at a predefinedratio to a total value of the secondary reserve computed using thefunction and the adjusted secondary dynamic reserve weight. Thepredefined ratio defining the total value between the primary reserveand secondary reserve may be initially fixed by the user that initiallyset-up the primary and secondary reserves, and provided the deposit toprovide the primary and secondary reserves. As discussed herein, whenthe dynamic reserve weights are constant (as in standard approaches toconverting cryptocurrencies), a user, which may be a malicious entityinitiating a cyberattack, performing an arbitration transaction based onthe price differences which may be part of the cyberattack, causes animpermanent loss, which may result in extraction of some value ofcryptocurrency from the reserves managed by the smart contract. Theprimary and/or secondary dynamic reserve weights are adjusted inresponse to the primary and/or secondary token prices provided by theprice oracle, reducing or eliminating the impermanent loss, providingcybersecurity against such malicious cyberattacks.

At least some implementations of the systems, methods, apparatus, and/orcode instructions described herein improve the technology of providingcybersecurity for distributed (i.e., non-centralized) exchanges ofcryptocurrencies, that use distributed ledgers. Smart contracts thatprovide distributed (i.e., non-centralized) exchanges ofcryptocurrencies enable virtually any user to set up such an exchange,and/or to use such an exchange to trade virtually any cryptocurrency toany other cryptocurrency. Such smart contacts, which are distributed(i.e., non-centralized) may then become potential targets forcyberattack and/or malicious behavior by entities (e.g., human and/orbots), for example, that attempt to reduce value of cryptocurrenciesfrom the reserves managed by the smart contracts by extraction of thevalue. It is noted that extraction of some value of the cryptocurrencyreserves may occur during legitimate transactions, in which case atleast some embodiments described herein may prevent or reduce suchlosses. The distributed ledger provides validity and trust that thetransactions are immutable, transparent, and therefore trustworthy, evenin the distributed environment. However, in an example, cyberattacks,malicious behavior which reduce cryptocurrencies from the reservesmanaged by the smart contact. Extraction of value from the tokenreserves may occur during legitimate transactions. Users may convert onecryptocurrency to another using smart contracts that manage pools ofcryptocurrencies without resorting to finding another user to buy orsell the corresponding cryptocurrency, in contrast to standard exchangesof standard currencies (e.g., FIAT) that rely on performing exchangesdirectly between buyers and sellers using a function that computes theprice of the cryptocurrencies independently of external market forces.In an example, entities may use standard and legitimate transactions toextract value from the cryptocurrency reserve(s). Users may convertcryptocurrencies with small number of tokens in circulation, and/orcryptocurrencies that are rarely traded (e.g., customizedcryptocurrencies, reward points issued by a store), for which standardcurrency exchange processes are irrelevant, for example, for which theprice cannot be properly determined due to lack of transactions and/orfor which buyers and sellers cannot be matched. Providing cybersecurityto such low volume traded cryptocurrencies is a technical challenge, forexample, in determining whether transactions in such low volume tradedcryptocurrencies is a cyberattack or legitimate. Moreover, suchdistributed exchanges enable users to covert virtually any of the largenumber of cryptocurrencies that exist and that may be created in thefuture (e.g., thousands) quickly and efficiently, making it even moredifficult to provide cybersecurity, for example, to distinguishlegitimate transactions from cyberattack using transactions appearing tobe legitimate, and/or to protect the token reserves from extraction ofvalue therefrom using legitimate standard transactions. Thousands ofcryptocurrencies cannot be traded using standard approaches sinceexchange rates between any two of the thousands of cryptocurrenciescannot be determined using standard approaches, in contrast to thelimited number of FIAT currencies for which trades between any twocurrencies is easily determined, further making it difficult to providecybersecurity, for example, to distinguish legitimate transactions fromcyberattack using transactions appearing to be legitimate.

At least some implementations of the systems, methods, apparatus, and/orcode instructions described herein address technical problems ofproviding cybersecurity to distributed (i.e., non-centralized) smartcontracts executing on a blockchain that manage pools ofcryptocurrencies that provide cryptocurrency conversion services, usingdistributed ledgers.

The technical problems are directly tied to, and arose from improvementsin the technical field of cryptocurrencies, smart contracts, anddistributed ledgers such a blockchain. For example, cyberattacks may bedisguised as standard transactions in an effort to extractcryptocurrencies from reserves managed by the smart contract. Smartcontract based cryptocurrency transactions are non-analogous to trade ofreal world currencies (FOREX exchanges) such as FIAT, and therefore,exchange of cryptocurrencies incurs unique cybersecurity technologicalproblems that arise due to the new technological environment that hasbeen created to support and exchange the cryptocurrencies, with noanalogy to standard FIAT exchanges. For example, standard FIATtransactions do not result in extraction of value from FIAT reserves,but standard cryptocurrency transactions may result in extraction ofvalue from cryptocurrency reserves. As such, the technical problemsdescribed herein and the solutions to the technical problems describedherein have no counterparts prior to the development of suchtechnologies. For example, standard conversion of FIAT currency is doneby matching buyers and sellers. The price the buyers and sellers agreeon is the market price, which is used for other currency transactions.Manipulation of exchange prices and/or manipulation of exchanges isdifficult to perform for standard FIAT currency. The pricing andconversion processes of cryptocurrencies using distributed smartcontracts managing pools of the cryptocurrencies is entirely different,which leads to technical problems and solutions that are entirelydifferent, for example, cyberattack such as stealing of cryptocurrencyfunds from reserves managed by smart contracts by manipulation ofcryptocurrency prices and/or transactions of cryptocurrencies.

One technical problem addressed by at least some implementations of thesystems, methods, apparatus, and/or code instructions described hereinrelates to extraction of value from cryptocurrency reserves, sometimesreferred to impermanent loss. Impermanent loss may occur during standardlegitimate cryptocurrency transactions. Such legitimate cryptocurrencytransactions may be initiated as a cyberattack in which a maliciousentity (e.g., human and/or bot) designs such transactions to extractcryptocurrency funds from cryptocurrency reserves managed by a smartcontract. Impermanent loss may be experienced by users that providecryptocurrency in order to provide liquidity for smart contractsproviding distributed cryptocurrency exchange services based ondistributed ledgers such as blockchain. Impermanent loss is thedifference between holding tokens in the smart contract and holding thetokens in a wallet. Such loss may occur since the smart contactproviding token exchange services is disconnected from external marketprices, with the price of the tokens being dynamically computed usingmathematical functions based on a fixed defined weight ratio between thetypes of tokens stored by the smart contract, and the amount of tokensstored by the smart contact. When the price of the token computed by thesmart contract deviates from a price available elsewhere, an arbitrageopportunity is created. The arbitrage opportunity may be created duringa cyberattack, for example, when a malicious entity (e.g., human hacker,malicious code) manipulates the prices of the token (e.g., directly, bygeneration of specially designed transactions) to create the arbitrateopportunity. The malicious entity (or another arbitrageur user) may thenbuy the underpriced token or sell the overpriced token until pricesoffered by the smart contract match the price available elsewhere. Thearbitrager effectively re-balances the distribution of types of tokensof the smart contract, to re-obtain the fixed defined weight ratio.During this transaction, which may be a form of cyberattack, the profitextracted by the arbitrageurs is effectively removed from the user thatprovided the liquidity, resulting in the impermanent loss, wherecryptocurrency has been extracted from the reserves managed by the smartcontract. It is noted that the impermanent loss, which is reduced and/orprevented by at least some embodiments, may be experienced by standardoperation of the smart contract during cryptocurrency transactions,without necessarily occurring as part of a cyberattack. The inability todistinguish impermanent loss as a cyberattack rather than normaloperations makes it difficult to detect such cyberattacks and/or toprotect against such cyberattacks.

An example of an approach that uses the fixed defined weight ratio(i.e., fixed weight), also termed Reserve Ratio Constant, is describedfor example, with reference to “Methods for Exchanging and EvaluatingVirtual Currency”, Application No. IL2018/050023 (Publication No.WO2018/127932), filed on Jan. 8, 2018, which shares at least oneinventor with the instant application, incorporated herein by referencein its entirety. Following is a formula for determining a price of atoken being exchanged, using a fixed weight:

${Tp} = \frac{Tr}{Tt*Rr}$

Wherein:

Tr denotes Total Reserve in underlying Tokens,

Tt denotes Total Tokens in circulation,

Rr denotes a Reserve Ratio Constant, which is the fixed weight describedherein, and

Tp denotes the price of the Token in terms of an underlying Token.

At least some implementations of the systems, methods, apparatus, and/orcode instructions described herein eliminate or reduce impermanent lossthat may occur during cyberattacks and/or that may occur as part ofstandard non-attack transactions. The elimination or reduction ofimpermanent loss is obtained, in at least some embodiments, by thedynamic adjustment of the dynamic reserve weight when the value of thereserve tokens stored by the smart contact change (which were staked bya user providing liquidity at an initial staked value and amount. Forexample, a user may stake 100 token-A worth $100 and receive 50 token-Aworth $50 at the end of the process). The reserve weight is defined pertoken type, and defines the relative proportion of the value of therespective token type. For example, when the reserve weight is 0.4 forthe primary token, and 0.6 for the secondary token, the total value ofthe primary token held in reserve by the smart contact (i.e., value pertoken*number of primary tokens held in reserve) is 40% of the totalvalue of tokens, while the total value of the secondary token held inreserve is 60%. The dynamic reserve weight is adjusted to dynamicallyindicate a balanced state, where the current value of the reserve tokensmatches the value of the initially staked tokens. Since the balancedstate is dynamically maintained, impermanent loss resulting from anunbalanced state is prevented or reduced. In contrast, other approachesthat use a fixed value for the reserve weight “lock” the perceived valueof each reserve token. The price per token is computed by suchapproaches by assuming that the total value of each reserve token isequal to the share of the pool based on the weight distribution, whichresults in impermanent loss, as described herein.

Another technical problem addressed by at least some implementations ofthe systems, methods, apparatus, and/or code instructions describedherein relates to price slippage that may occur during cyberattacksand/or that may occur as part of standard non-attack transactions. Priceslippage refers to the difference between the expected price before atransaction is executed and the actual price at which it is executed.Slippage occurs due to the dynamic variables of the function used tocompute the price of the token. Every transaction changes the dynamicvariables, which results in a slight change in price. The larger thetransaction size of a token relative to its liquidity depth, the higherthe price slippage. A substantial amount of liquidity is required to bestaked in a pool in order to reduce the price slippage.

At least some implementations of the systems, methods, apparatus, and/orcode instructions described herein reduce the amount of price slippagethat would otherwise occur using standard approaches, by virtuallyamplifying the staked reserves for computing conversions. The virtualamplification allows more token conversions to occur on the pool and/orallows larger conversions to occur on the pool, due to the reduced priceslippage. The increase in conversions and/or size of conversionsincreases the amount of collected fees for the user providing theliquidity to the pool.

Yet another technical problem addressed by at least some implementationsof the systems, methods, apparatus, and/or code instructions describedherein relates to funding and/or liquidity constraints that arise byrequiring users that contribute liquidity to smart contacts providingtoken conversion services. In standard approaches, each pool of eachsmart contact includes at least 2 tokens. The user is required toprovide funds to each type of token according to the fixed weight thatdefines the ratio between the types of tokens, for example, equal. Theuser is provided with a single type of pool token, which forces the userproviding liquidity to add or remove liquidity to all reserve tokens atthe fixed reserve weights. As such, the user holds both token types in aproportion defined by the fixed reserve weights (or is required toconvert some of the deposited token type into the other token typeaccording to the fixed reserve weight). The user can no longer maintaina long position on one of the token types. Moreover, if a user were toattempt to deposit (i.e., stake) one type of token into the reserve poolof the smart contract (or to deposit both types of tokens in aproportion that is different than the fixed reserve weights), the valueof the reserve balance of the type of token would change since thevalues of the reserve weights are fixed. The change in the reservebalance would reduce the price of the primary type of tokens and/orcreate an arbitrage opportunity that would remove the increased valuefrom the pool, resulting in an impermanent loss to the depositing user.

At least some implementations of the systems, methods, apparatus, and/orcode instructions described herein enable users to provide liquiditywith 100% exposure to one of the two types of tokens held in reserve bythe smart contact, and/or to define the percent of exposure to each oneof the two types of tokens held in reserve. The exposure to teach one ofthe two types of tokens is enabled by the minting of two types of pooltokens, corresponding to the two types of tokens held in reserve, andthe dynamic computation of the dynamic reserve weights. The price ofeach type of pool token tracks the price of the corresponding stakedtype of pool token held in reserve by the smart contract. Moreover, bydynamically computing the dynamic reserve weight, the value of thereserve balance remains constant even when one type of token isdeposited into the reserve and/or even when two types of tokens aredeposited in any proportion. The maintenance of the value of the reservebalance by the dynamic reserved weights eliminates or reduces the riskof reduction in price of the reserve tokens and/or the arbitrateopportunity that causes impermanent loss.

Before explaining at least one embodiment of the invention in detail, itis to be understood that the invention is not necessarily limited in itsapplication to the details of construction and the arrangement of thecomponents and/or methods set forth in the following description and/orillustrated in the drawings and/or the Examples. The invention iscapable of other embodiments or of being practiced or carried out invarious ways.

The present invention may be a system, a method, and/or a computerprogram product. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, and any suitable combination of theforegoing. A computer readable storage medium, as used herein, is not tobe construed as being transitory signals per se, such as radio waves orother freely propagating electromagnetic waves, electromagnetic wavespropagating through a waveguide or other transmission media (e.g., lightpulses passing through a fiber-optic cable), or electrical signalstransmitted through a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Smalltalk, C++ or the like, andconventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

Reference is now made to FIG. 1, which is a block diagram of componentsof a system 100 for executing transactions of cryptocurrencies based ondynamically adjusted dynamic reserve weights for providing cybersecurityof a smart contact, in accordance with some embodiments of the presentinvention. Reference is also made to FIG. 2, which is a flowchart of anexemplary process of executing transactions of cryptocurrencies based ondynamically adjusted dynamic reserve weight for providing cybersecurityof a smart contract, in accordance with some embodiments of the presentinvention. Reference is also made to FIG. 3, which is a flowchart of anexemplary process of depositing a selected percentage of a primary tokenand/or a selected percentage of a secondary token into the correspondingtoken reserve, in accordance with some embodiments of the presentinvention. Reference is also made to FIG. 4, which is a flowchart of anexemplary process of withdrawing a selected amount of a primary tokenand/or a selected amount of a secondary token from the correspondingtoken reserve, in accordance with some embodiments of the presentinvention. System 100 may implement the methods described with referenceto FIGS. 2-4.

System 100 includes multiple computing devices 102 each acting as arespective network node (one computing device 102 acting as one networknode shown for clarity and simplicity). Computing devices 102 may begeographically distributed. Exemplary implementations of computingdevices 102 include, for example, a server, a computing cloud, a virtualmachine, a virtual server, a client terminal, a desk top computer, akiosk, a mobile device, a Smartphone, a Tablet computer, a laptopcomputer, a wearable computer, augmented reality glasses, a glassescomputer, and a watch computer.

Each computing devices 102 includes one or more hardware processors 104,for example, a central processing unit(s) (CPU), a graphics processingunit(s) (GPU), field programmable gate array(s) (FPGA), digital signalprocessor(s) (DSP), and application specific integrated circuit(s)(ASIC). Processor(s) 104 may include one or more processors (homogenousor heterogeneous), which may be arranged for parallel processing, asclusters and/or as one or more multi core processing units.

Each computing devices 102 includes a memory 106 that stores codeinstructions executable by hardware processor(s) 102, for example, arandom access memory (RAM), read-only memory (ROM), and/or a storagedevice, for example, non-volatile memory, magnetic media, semiconductormemory devices, hard drive, removable storage, and optical media (e.g.,DVD, CD-ROM).

Memory 106 stores smart contract code 108 (also referred to asdistributed smart contract code) that executes on a blockchain 110.

Smart contact code 108 implements one or more features and/or acts ofthe method described with reference to FIGS. 2-4 when executed byhardware processor(s) 104. Smart contract code 108 manages a primarycryptocurrency (also referred to herein as a primary token) reserve 108Aand a secondary cryptocurrency (also referred to herein as a secondarytoken) reserve 108B. Smart contact code 108 provides services forexchanging between the primary token and secondary token using reserves108A-B, and/or for depositing additional primary and/or secondary tokensinto reserves 108A and/or 108B, and/or for withdrawing tokens fromreserves 108A and/or 108B, as described herein. Transactions executed bysmart contract code 108 on reserves 108A and/or 108B are recorded in adistributed ledger 108C which may be stored on blockchain 110.

It is noted that different smart contracts 108 executing on the samecomputing device 102 and/or on different computing devices 102 mayprovide exchange services and/or deposit services and/or withdrawalservices for different combinations of cryptocurrencies. Optionally,each smart contract 108 manages two reserves 108A-B that hold two typesof cryptocurrencies, as set-up by a user acting as a liquidity provider.The user may select which two types of currencies will be stored inreserves 108A-B of the respective smart contract code 108.

Computing devices 102 includes a data storage device 112 for storingdata. Data storage device 112 may be implemented as, for example, amemory, a local hard-drive, virtual storage, a removable storage unit,an optical disk, a storage device, and/or as a remote server and/orcomputing cloud (e.g., accessed using a network connection). It is notedthat one or more of blockchain 110, smart contract code 108, reserves108A and/or 108B, and ledger 108C, or portions thereof, may be stored indata storage device 112, and loaded from data storage device 112 intomemory 106 for execution by processor(s) 104.

Computing devices 102 acting as network nodes communicate with eachother for updating their respective copies of blockchain 110 and/ordistributed transaction ledger 108C.

Each computing device 102 provides token exchanges services, and/ortoken deposit services, and/or token withdrawal services to multipleclient terminals 114 over a network 116.

Computing device 102 may include a network interface 118, for example, anetwork interface card, a wireless interface to connect to a wirelessnetwork, a physical interface for connecting to a cable for networkconnectivity, a virtual interface implemented in software, networkcommunication software providing higher layers of network connectivity,and/or combinations of the aforementioned.

Network 116 may be implemented as, for example, the internet, a localarea network, a virtual network, a wireless network, a cellular network,a local bus, a point to point link (e.g., wired), and/or combinations ofthe aforementioned.

Client terminal 114 may be implemented as, for example, a server, acomputing cloud, a virtual machine, a virtual server, a desktopcomputer, a kiosk, a mobile device, a Smartphone, a Tablet computer, alaptop computer, a wearable computer, augmented reality glasses, aglasses computer, and a watch computer.

Client terminal 114, may access smart contract code 108 and/or interactwith smart contract code 108 for performing transactions (e.g.,exchange, deposit, withdrawal), for example, by accessible softwareinterfaces of the smart contract function code 108, for example, using agraphical user interface (GUI), application programming interface (API),software development kit (SDK), and/or transmission of messagesspecifying certain functions for execution. Smart contract code 108 maybe accessed directly, and/or indirectly via another application thataccesses smart contract code 108 to perform transactions, for example, awallet managing application.

Smart contract code 108 receives data from price oracle code 120A (asdescribed herein), which may be executed by a price oracle server 120connected to network 116. Alternatively or additionally, price oraclecode 120A is implemented within smart contract code 108.

Computing device 102 and/or client terminal(s) 114 include and/or are incommunication with one or more physical user interfaces 122 that includea mechanism for a user to enter data (e.g., for performing a transactionwith the primary and/or secondary tokens) and/or view data (e.g., viewthe results of the transaction). User interface 122 may present a GUIthat includes the mechanism for entering data and/or viewing data.Exemplary user interfaces 122 include, for example, one or more of, atouchscreen, a display, gesture activation devices, a keyboard, a mouse,and voice activated software using speakers and microphone.

Referring now back to FIG. 2, at 202, a smart contract executed on ablockchain by a server connected to a network, where multiple clientterminals access the smart contract for performing transactions usingcryptocurrencies is provided.

The smart contract manages a primary reserve of a primary token of aprimary cryptocurrency and a secondary reserve of a secondary token of asecondary cryptocurrency. Each reserve is set to respective initialstaked value, according to the initial value provided by a user (e.g.,liquidity provider).

A respective percentage of a total value of the primary token and thesecondary tokens in the respective reserve is set according to arespective dynamic reserve weight (also referred to herein as dynamicweight). For example, when the dynamic reserve weight is 0.2, and 200primary tokens are stored in the primary token reserve, the primaryreserve value calculated as (200*primary reserve value)/0.2 in the poolis representing 20% of the total pool value.

A respective current value of the respective primary token and/orsecondary token is automatically computed using a function of the amountof respective token in the reserves, amount of respective token incirculation, and the respective dynamic reserve weight. An exemplaryfunction, for computing the price of the respective token (i.e., primarytoken, or secondary token) is denoted as:

${Tp} = \frac{Tr}{Tt*Rr}$

Wherein:

Tr denotes the amount of respective (i.e., primary, secondary) tokens inthe respective (i.e., primary, secondary) reserve,

Tt denotes the amount of respective tokens in circulation,

Rr denotes the dynamic reserve weight, and

Tp denotes the price of the respective (i.e., primary, secondary) token,optionally in terms of an underlying Token from which the respectivetoken is derived from (e.g., Etherium).

It is noted that other functions based on the dynamic reserve weight maybe implemented.

At 204, a transaction request is received for the primary token. Forsake of simplicity and clarity of explanation, the term primary token isnot necessarily referring to a particular token. The term primary tokenmay sometimes refer to the primary token (e.g., denoted TKN) and maysometimes refer to the secondary token (e.g., denoted BNT).

Optionally, at 204A, the transaction request is for conversion of theprimary token into the secondary token, or for converting the secondarytoken into the primary token. An exemplary process for conversion oftokens is described with reference to FIG. 2.

Alternatively, at 204B, the transaction request comprises adding aprimary deposit amount of the primary token to the primary token reserveand/or adding a secondary deposit amount of the secondary token to thesecondary token reserve. Details of an exemplary process for addingtokens to the reserve(s) are described with reference to FIG. 3.

Alternatively, at 204C, the transaction request comprises removing aprimary withdrawal amount of the primary token from the primary tokenreserve and/or removing a secondary withdrawal amount of the secondarytoken from the secondary token reserve. Details of an exemplary processfor withdrawing tokens from the reserve(s) is described with referenceto FIG. 4.

At 206, the amount and/or total value of the primary token reserveand/or the amount and/or total value of the secondary token reserve maybe virtually amplified. The virtual amplification may reduce conversionslippage, and/or increase overall fees collected from the transaction.

The virtually amplified amount may be used for computation of theconversion transaction, rather than the actual amount. The function forcomputing the price of the primary token and/or secondary token may becomputed using the virtually amplified amount of the primary tokenreserve and/or the secondary token reserve.

The virtually amplified amount of the primary token reserve and/or thesecondary token reserve may be computed by multiplying the initialstaked value of the respective primary token and/or the secondary tokenby an amplification value, and subtracting therefrom, a differencebetween the initial staked value of the respective primary and/orsecondary token and the current balance of the respective primary and/orsecondary token in the reserves. For example, using the followingexemplary equations:

PrimaryCurrentBalance_Amp=PrimaryStakedBalance*Amp−(PrimaryStakedBalance−PrimaryCurrentBalance)

SecondaryCurrentBalance_Amp=SecondaryStakedBalance*Amp−(SecondaryStakedBalance−SecondaryCurrentBalance)

where:

-   -   Amp denotes the amplification value,    -   PrimaryStakedBalance denotes the balance of Primary tokens        initially staked in the primary token reserve,    -   PrimaryCurrentBalance denotes the current balance of Primary        tokens in the primary token reserve,    -   PrimaryCurrentBalance_Amp denotes the result of the calculation        and the balance used in the conversion calculation instead of        PrimaryCurrentBalance,    -   SecondaryStakedBalance denotes the balance of Secondary tokens        staked in the secondary token reserve,    -   SecondaryCurrentBalance denotes the current balance of Secondary        tokens in the secondary token reserve, and    -   SecondaryCurrentBalance_Amp denotes the result of the        calculation and the balance used in the conversion calculation        instead of SecondaryCurrentBalance.

At 208, a price oracle is accessed to obtain an external (optionallyreal time) price of the primary token. The price oracle may be anexternal oracle (e.g., external smart contract that is updated by aserver), and/or an internal oracle (e.g., within the smart contract codeitself). In the case of the external oracle, an external server mayupdate the current respective token price by writing to another smartcontract that the smart contract may read from. The price oracleprovides external (optionally real time) prices for tokens which areprocessed using transactions as described herein.

Optionally, a failure of the price oracle in providing the externalprice of the primary token is detected. For example, the price oracle isdown and is not currently providing the external prices, and/or theprices obtained from the price oracle are incorrect (e.g., due to anexceptionally long delay such that the prices provided are old and notreflective of the external price). In response to detecting the failureof the price oracle, the transaction request (e.g., as described withreference to 214) is executed by computing the value of the primarytoken using the function and/or the dynamic reserve weights which werecomputed prior to the failure of the price oracle, for example, thefunction and/or the dynamic reserve weights which were updated after thelast transaction. Effectively, the dynamic reserve weights temporarilybecome static reserve weights. Misbalances between the two tokenreserves may be re-balanced by arbitrageurs placing conversiontransactions based on price differences between token prices computed bythe function and prices of the tokens available from other sources. Theconversions performed by the arbitrageurs help rebalance the two tokenreserves.

The price oracle may be monitored to detect restoration of the priceoracle in providing the external price of the primary token.

When the price oracle is restored, the updated total value of primarytoken and/or updated total value of the secondary token may be computedbased on the restored price oracle (e.g., as in 210). When updated totalvalue of the primary and/or secondary token reserves is unequal to theinitial staked value of the corresponding primary token and/or secondarytoken, each respective dynamic weight is adjusted to an adjusted weight(e.g., as in 212). The adjusted weight indicates a state of the primaryand secondary token reserves that forces the total value of the primaryand/or secondary tokens to return to the respective initial stakedvalue, which brings the primary reserve pool and/or the secondaryreserve pool to a desired state. The total value of the primary tokensstored in the reserve and/or the secondary tokens stored in the reserve,computed by the function using the adjusted dynamic weights after beingincreased or decreased by a target amount of primary and/or secondarytokens, is equal to the initial staked value.

At 210, an updated total value of the primary token reserve (alsoreferred to as primary reserve balance) and/or an updated total value ofthe secondary token reserve (also referred to as secondary reservebalance) is computed according to the external price provided by theprice oracle. For example, the external price of the primary tokenobtained from the price oracle is multiplied by the number of primarytokens in the reserve to obtain the updated total value of the primarytoken reserve, and/or the external price of the secondary token obtainedfrom the price oracle is multiplied by the number of secondary tokens inthe reserve to obtain the updated total value of the secondary tokenreserve.

At 212, the primary dynamic reserve weight is adjusted to a primaryadjusted dynamic reserve weight, and/or the secondary dynamic reserveweight is adjusted to a secondary adjusted dynamic reserve weight. Thedynamic reserve weights are adjusted in response to a price of theprimary and/or secondary tokens as provided by the price oracle, that isdifferent than the price of the primary and/or secondary tokens arecomputed by the function. As discussed herein, when the dynamic reserveweights are constant, a user performing an arbitration transactioncauses an impermanent loss. The primary and/or secondary dynamic reserveweights are adjusted in response to the primary and/or secondary tokenprices provided by the price oracle, reducing or eliminating theimpermanent loss. It is noted that the primary reserve and secondaryreserve represent the external price ratio between the primary token andsecondary token. After a conversion transaction is performed on theprimary reserve and/or the secondary reserve, a predefined ratio betweenthe total value of the primary reserve and the total value of thesecondary reserve is lost, resulting in a state of imbalance. Thebalanced state, where the primary and secondary reserves back to thepredefined ratio are restored is obtained by an arbitration opportunitycreated based on the price difference between the price of the primaryand/or secondary tokens computed by the function using the dynamicreserve weights and the external price provided by the price oracle. Thearbitration transaction, performed after a conversion transaction,restores the balanced state. When the arbitration transaction isperformed after the conversion transaction and the external price of thetoken(s) has not changed, no impermanent loss occurs. When the arbitragetransaction is performed after the conversion transaction and theexternal price of the token(s) has changed, impermanent loss occurs. Theimpermanent loss may be reduced or eliminated by the adjustment of thedynamic reserve weight(s) which may maintain the balanced state, asdescribed herein.

Optionally, the adjustment of the primary dynamic reserve weight and/orthe secondary dynamic reserve weight is in response to the updated totalvalue of primary reserve (computed based on the price oracle) beingequal to the initial staked value of the primary reserve. The adjustmentis performed to select the primary adjusted dynamic reserve weightand/or the secondary adjusted dynamic reserve weights that when used bythe function to compute the price of the primary tokens stored in theprimary reserve, a total value of the primary reserve is equal to theinitial staked value of the primary reserve, and the total value of theprimary reserve is maintained at a predefined ratio to a total value ofthe secondary reserve computed using the function and the adjustedsecondary dynamic reserve weight.

The predefined ratio defining the total value between the primaryreserve and secondary reserve may be initially fixed by the user thatinitially set-up the primary and secondary reserves, and provided thedeposit to provide the primary and secondary reserves.

Alternatively, the adjustment of the primary dynamic reserve weightand/or the secondary dynamic reserve weight is in response to theupdated total value of the primary reserve computed based on the priceoracle being unequal to the initial staked value of the primary reserve.The adjustment is performed to select the primary adjusted dynamicreserve weight and/or the secondary adjusted dynamic reserve weightsthat when used by the function to compute the price of the primarytokens stored in the primary reserve after the primary reserve isincreased or decreased by a target amount of primary tokens, is equal tothe initial staked value of the primary reserve, and the total value ofthe primary reserve is maintained at a predefined ratio to a total valueof the secondary reserve computed using the function and the adjustedsecondary dynamic reserve weight. The target amount represents anarbitration amount (i.e., price difference between the price computed bythe function and the external price provided by the oracle) to close thedifference between the updated total value of the primary reservecomputed based on the price oracle and the initial staked value of theprimary reserve, and/or to close the difference between the updatedtotal value of the primary reserve and the updated total value of thesecondary reserve. For example, when the difference is 10 TKN (i.e., theprimary reserve is missing 10 TKN), the adjusted dynamic reserve weightscreate an arbitration opportunity to add 10 TKN to the primary reserve.It is noted that the current price of the primary token computed by thefunction using the adjusted weight(s) and the primary reserve, prior tobeing increased or decreased by the target amount of primary token, isdifferent than the external price of the primary token provided by theprice oracle.

The target amount may be the target amount of primary tokens that areconverted into the secondary token.

After execution of a subsequent transaction request for the targetamount of primary token corresponding to the increase or decrease of theprimary token, the current price of the primary token computed by thefunction using the adjusted dynamic reserve weight(s) and the primaryreserve after being increased or decreased by the target amount, isequal to the external price of the primary token provided by the priceoracle. Moreover, the total value of primary reserve computed by thefunction using the adjusted weight and the amount of primary tokensstored in the primary reserve after being increased or decreased by thetarget amount, is equal to the initial staked value of the primaryreserve. Further, the predefined ratio of the price of the primary tokenrelative to the price of the secondary token computed by the functionafter the execution of the subsequent transaction request, becomes equalto the ratio of the price of the primary token relative to the price ofthe secondary token obtained from the price oracle. For example, afterthe created arbitrage opportunity (to convert the target amount oftokens) is used by the arbitrate transaction (i.e., the subsequenttransaction), the prices of the tokens computed using the function andthe adjusted dynamic weights are equal to the external prices providedby the oracle, closing the arbitrage opportunity while restoring thebalanced state.

Optionally, the primary and/or secondary dynamic reserve weights arecomputed using a Lambert W function.

Optionally, the primary dynamic reserve weight of the primary token isdenoted as 1/(1+x), and the secondary dynamic reserve weight of thesecondary token is denoted as x/(1+x), wherein:

$x = {\frac{T}{b\; p} \cdot {\sum\limits_{n = 1}^{\infty}\;{\frac{n^{n - 1}}{n!} \cdot \left( \frac{T\mspace{11mu}\log\mspace{11mu}\left( \frac{T}{t} \right)}{b\; p} \right)^{n - 1}}}}$

T=primary token reserve staked balance,

b=secondary token reserve current balance,

p=ratio of primary token/secondary token off-chain price as provided bythe price oracle,

t=secondary token reserve current balance as computed by the function.

Additional details describing the derivation of the above values for thedynamic reserve weights are now provided.

Let:

BNT denote the primary token,

TKN denote the secondary token,

w₁ denote the BNT dynamic weight,

w₂ denote the TKN dynamic weight,

b denote the BNT reserve current balance,

t denote the TKN reserve current balance,

T denote the initial staked TKN balance,

p denotes the TKN/BNT off-chain price, obtained from the price oracle

q denotes the TKN/BNT on-chain spot price, computed using the functionwith the current values of the respective dynamic weights, before beingincreased and/or decreased by a target amount (e.g., before an arbitrageconversion occurs),

r denotes the TKN/BNT on-chain spot price, computed using the functionwith the current values of the respective dynamic weights, after beingincreased and/or decreased by a target amount (e.g., after the arbitrageconversion occurs).

when T≥t:

the target amount (e.g., arbitrage incentive) is for converting TKN toBNT, such that r will be equal to p. The conversion transaction (e.g.,arbitrage conversion) will also impact t to become equal to T. In otherwords, the conversion (e.g., arbitrage conversion) is for an amount ofTNK denoted by T−t, to be converted to BNT:

-   -   The result of converting T−t amount of TKN is b(1−(t/T)^(w2/w1))        amount of BNT.    -   The TKN reserve balance after the conversion (e.g., arbitrage        conversion) occurs is T.    -   The BNT reserve balance after the conversion (e.g., arbitrage        conversion) occurs is b−b(1−(t/T)^(w2/w1)).    -   The TKN/BNT on-chain spot price after the conversion (e.g.,        arbitrage conversion) occurs is

$\mspace{20mu}{{\frac{T\; w_{1}\text{/}w_{2}}{b - {b\left( {1 - {\left( \frac{\text{?}}{T} \right)\text{?}}} \right)}}.\text{?}}\text{indicates text missing or illegible when filed}}$

When T and/or p change, w₁ and/or w₂ are recomputed such that theconversion transaction (e.g., arbitrage incentive) of making r equal top will be equivalent to converting an amount of TKN denoted by T−t toBNT, which increases the TKN reserve balance (denoted t) to be equal toTKN initial staked balance (denoted T).

Let x denote w2/w1 in the section below:

$\mspace{20mu}{r = {\left. p\Rightarrow\mspace{20mu}\frac{T\text{/}\text{?}}{b - {b\left( {1 - {\left( \frac{\text{?}}{\text{?}} \right)\text{?}}} \right)}} \right. = {\left. p\Rightarrow\mspace{20mu} T \right. = {\left. {x\; b\;{p\left( {1 - \left( {1 - {\left( \frac{\text{?}}{T} \right)\text{?}}} \right)} \right)}}\Rightarrow\mspace{20mu} T \right. = {\left. {x\; b\;{p\left( \frac{\text{?}}{T} \right)}\text{?}}\Rightarrow\mspace{20mu}{T\text{?}} \right. = {\left. {x\; b\; p\; t\;\text{?}}\Rightarrow x \right. = {\frac{W\left( \frac{T\;{\log\left( \frac{\text{?}}{T} \right)}}{b\; p} \right)}{\log\left( \frac{t}{T} \right)} = {\frac{T}{b\; p} \cdot {\sum\limits_{n = 1}^{\infty}\;{\frac{n^{n - 1}}{n!} \cdot \left( \frac{T\mspace{11mu}\log\mspace{11mu}\left( \frac{T}{t} \right)}{b\; p} \right)^{n - 1}}}}}}}}}}}$$\mspace{79mu}{{{S{ince}}\mspace{14mu} x} = {{w_{2}\text{/}w_{1}\mspace{14mu}{and}\mspace{14mu} w_{2}} = {{1 - {w_{1}\text{:}w_{1}}} = {{\frac{1}{1 + x}\mspace{14mu}{and}\mspace{14mu} w_{2}} = \frac{x}{1 + x}}}}}$?indicates text missing or illegible when filed

At 214, the transaction request is executed. The transaction request isexecuted after the adjustment of each respective dynamic weight to theadjusted weight.

At 216, a fee in response to executing the conversion of the certaintoken is extracted. The fee may be defined by the creator of the tokenconversion service, which may be a single entity and/or created based ona vote submitted by multiple users.

The fee may be deducted from the converted tokens. Optionally, no feesare deducted from deposit transactions (e.g., as described withreference to FIG. 3) and/or from withdraw transactions (e.g., asdescribed with reference to FIG. 4).

The fee may be added to the initial staked reserve value of the certaintoken corresponding to the exchanged token and/or the token beingexchanged. The fee may be added by being deposited into the reserve ofthe respective token, as descried herein. The value of the pool token(which is provided to users that deposit tokens into the reserve, asdescribed herein) corresponding to the reserve token to which the feehas been added, is increased by the corresponding increase in theinitial staked value of the certain token. The price of the respectivepool token appreciates by the deposit of the fee to the staked balance,which the amount (i.e., number) of the respective tokens in therespective reserve remains constant. The initial ratio (e.g., 1:1)between pool token and staked balances changes, causing the pool tokento be worth more staked tokens.

Optionally, the fee is a dynamic fee that is dynamically computed, forexample, for each transactions. The dynamic fee may be set to create astronger incentive for the arbitrager and/or other user performing thetransaction to bring the secondary staked balance to match the secondarycurrent balance.

Optionally, the dynamic fee is reduced relative to a baseline fee (e.g.,indicating a discounted fee) when the total value and/or amount ofsecondary tokens of the secondary reserve (e.g., computed using anexternal price of the secondary token) is greater than the initialstaked value and/or amount of secondary tokens of the secondary reserve.The dynamic fee is increased (e.g., indicating a penalty) relative tothe baseline fee when the total value of the secondary reserve is lessthan the initial staked value of the secondary reserve. The baseline feemay be the initially set value of the fee.

The dynamic fee may be computed using the following equations:

dynamic fee=baseline fee*secondary ratio,

secondary ratio=staked amount of secondary tokens in the secondaryreserve/total amount of secondary tokens in the secondary reserve,(e.g., amount indicates the number of tokens, for example 100 tokensrather than the corresponding monetary value of the 100 tokens).

Optionally, the dynamic fee is extracted when the conversion transactionis from the primary token to the secondary token. Optionally, thebaseline fee, rather than the dynamic fee, is extracted when theconversion transaction is from the secondary token to the primary token.

Optionally, the dynamic fee is extracted, and the baseline fee is addedto the secondary staked balance of the second reserve.

At 218, the distributed ledger is updated. For example, a new blockchainblock is created with the details of the transaction, and distributed toother blockchain nodes for local updates of the blockchain.

At 220, one or more features described with reference to 204-218 areiterated. Optionally, a subsequent transaction is by a user (e.g.,human, robot) acting as an arbitrageur, in response to the createdarbitration opportunity. Alternatively, subsequent transactions are byusers that want to perform transactions for other reasons.

Referring now back to FIG. 3, at 302, the transaction request to add adeposit amount of one or both of the tokens is received. The depositedamount is added to the respective reserve,

The transaction request includes a division factor indicating how todivide the deposit amount into the two token reserves, for example, froman initial amount of $100, $70 is deposited into the primary tokenreserve and $30 is deposited into the secondary token reserve. Inanother example, the entire initial amount of $100 is deposited into theprimary token reserve, and nothing is deposited into the secondary tokenreserve. A selected percentage deposit amount is added to the primarytoken reserve and/or another selected percentage deposit amount is addedto the secondary token reserve.

The division factor is optionally selected by the user that provided thetransaction request. The division factor may vary, for each of thetokens, from 0-100% of the respective token. The user may select thepercentage for each token. The division factor is adjustable, optionallyby the user, and not fixed as in standard approaches.

Optionally, the division factor is to deposit 100% of the deposit amountof one token. For example, to deposit 100% of the amount into theprimary reserve of the primary token, or into the secondary reserve ofthe secondary token.

Alternatively, the division factor is to deposit the deposit amount intoboth token reserves at a defined percentage split, which may be 50/50,or other defined amount, for example, 90/10, 75/25, 30/70, and the like.It is noted that the deposit is not fixed to 50/50. The division factormay be defined by the user requesting the transaction.

At 304, the value of each of a primary deposit amount being depositedinto the primary token reserve, and/or a secondary deposit amount beingdeposited into the secondary token reserve are computed using thefunction and the respective dynamic reserve weight.

The price of the primary pool token may be computed as: number and/oramount of primary pool tokens in circulation divided by the numberand/or amount of staked primary token reserve. The price of thesecondary pool token may be computed as: number and/or amount ofsecondary pool tokens in circulation divided by the number and/or amountstaked secondary token reserve.

The value of the primary deposit amount and/or secondary deposit amountis computed prior to the execution of the transaction request in whichthe deposit is actually made (as described with reference to 306) and/orgeneration of the corresponding pool tokens (as described with referenceto 308).

At 306, the deposit value of one or both tokens (as defined by thedivision factor) is added to the respective reserve. The deposited valueincreases the initial staked value of the primary and/or secondary tokenreserve, and the deposited value increases the value of the primaryand/or secondary token reserve (i.e. the current balance in therespective token reserve).

At 308, an amount of a primary and/or secondary pool token correspondingto the value deposited into one or both token reserves is generated, forexample, minted. A primary amount of the primary pool tokencorresponding to the deposit amount of the primary token is minted,and/or a secondary amount of the secondary pool token corresponding tothe deposit amount of the secondary token is minted.

The number of primary pool tokens that is minted may be computed as:deposited amount of primary tokens*price of primary pool token. Thenumber of secondary pool tokens that is minted may be computed as:deposited amount of secondary tokens*price of secondary pool token.

For the deposit amount added to the primary token reserve, an amount ofa primary pool token that corresponds to the deposit amount isgenerated. The primary pool token may later be used to withdraw from theprimary token reserve, i.e., to withdraw an amount from the primarytoken reserve that corresponds to the amount of the primary pool token.For the deposit amount added to the secondary token reserve, an amountof a secondary pool token that corresponds to the deposit amount isgenerated. The secondary pool token may later be used to withdraw fromthe secondary token reserve, i.e., to withdraw an amount from thesecondary token reserve that corresponds to the amount of the secondarypool token.

Each of the primary and secondary tokens held in reserve by the smartcontact has a certain ratio between the total staked amount of therespective token (e.g., the initial staked amount of the respectivetoken that is deposited into the token reserve and/or additional stakedamounts, also referred to herein as previously staked) and the totalamount of respective pool tokens that are issued. The price of therespective pool token is determined according to the ratio for therespective pool token. When a deposit is made into one or both tokenreserves, the ratio is maintained, and the price of the pool tokenremains constant, before and after the deposit. The value (i.e., price)of each of the primary and secondary pool token remains constant, beforethe deposit transaction, and after the deposit transaction request isexecuted. The ratio between the total value of the total amount ofprimary pool tokens and the previous (e.g., initial) staked value of theprimary token remains constant, and/or the ratio between the total valueof the total amount of secondary pool tokens and the previously staked(e.g., initial) value of the secondary token remains constant.

It is noted that the transaction request, as described with reference to306 and 308, is executed prior to the accessing the price oracle (asdescribed with reference to 308), prior to computing to the updatedtotal value (as described with reference to 312), and prior to theadjustment of each respective dynamic value (as described with referenceto 314).

At 310, the external price of the primary and/or secondary token isobtained by accessing the price oracle, for example, as described withreference to 208 of FIG. 2

At 312, the updated total value of the primary token reserve and/or thesecondary token reserve is computed according to the external price ofthe primary and/or secondary tokens, for example, as described withreference to 210 of FIG. 2.

At 314, the dynamic weight for the primary token and/or the dynamicweight for the secondary token are adjusted according to the externalprice of the primary token and/or the secondary token, for example, asdescribed with reference to 212 of FIG. 2.

Referring now back to FIG. 4, at 402, the transaction request towithdraw an amount from one or both of the token reserves is received.The transactions request includes an amount of the primary pool tokenand/or the secondary pool token.

At 404, the value of each of a primary withdrawal value being withdrawnfrom the primary token reserve, and/or a secondary withdrawal valuebeing withdrawn from the secondary token reserve are computed using thefunction and the respective dynamic reserve weight. The primary and/orsecondary withdrawal value of the primary and/or secondary tokencorrespond to the amount of the provided primary and/or secondary pooltokens.

At 406, primary withdrawal value and/or the secondary withdrawal valuemay be compared to the primary token reserve and/or to the secondarytoken reserve, to make sure that enough tokens are available. When theprimary token reserve and/or the secondary token reserve do not includesufficient amount for withdrawal to provide the full amountcorresponding to the primary and/or secondary pool tokens, the user maybe provided with one or more options, for example, the respective valueis provided to the user when other users add tokens to the reserve, theuser may be provided the option to abort the transaction, and/or to beprovided with the available amount, and/or to obtain the remainingamount by conversion from the other token reserve (when relevant).

The primary withdrawal value and/or the secondary withdrawal value arecomputed prior to the execution of the transaction request in which thewithdrawal is actually made (as described with reference to 408) and/ordestroying of the corresponding pool tokens (as described with referenceto 410).

At 408, the primary and/or secondary pool tokens (provided forwithdrawal of corresponding primary and/or secondary tokens) aredestroyed.

At 410, an amount of primary tokens corresponding to the primarywithdrawal value of the primary pool tokens is withdrawn from theprimary reserve, and/or an amount of secondary tokens corresponding tothe secondary withdrawal value of the secondary pool tokens is withdrawnfrom the secondary reserve. The withdrawn primary and/or secondarytokens may be provided to the user, for example, deposited into adigital wallet of the user.

The withdrawn value decreases the initial staked value of the primaryand/or secondary token reserve, and the withdrawn value decreases thevalue of the primary and/or secondary token reserve (i.e. the currentbalance in the respective token reserve).

Each of the primary and secondary tokens held in reserve by the smartcontact has a certain ratio between the total staked amount of therespective token (e.g., the initial staked amount of the respectivetoken that is deposited into the token reserve and/or additional stakedamounts, also referred to herein as previously staked) and the totalamount of respective pool tokens that are issued. The price of therespective pool token is determined according to the ratio for therespective pool token. When a withdrawal from one or both token reservesis made, the ratio is maintained, and the price of the pool tokenremains constant, before and after the withdrawal. The value (i.e.,price) of each of the primary and secondary pool token remains constant,before the withdrawal transaction, and after the withdrawal transactionrequest is executed. The ratio between the total value of the totalamount of primary pool tokens and the previously (e.g., initial) stakedvalue of the primary token remains constant, and/or the ratio betweenthe total value of the total amount of secondary pool tokens and thepreviously (e.g., initial) staked value of the secondary token remainsconstant.

It is noted that the transaction request, as described with reference to408 and 410, is executed prior to the accessing the price oracle (asdescribed with reference to 412), prior to computing to the updatedtotal value (as described with reference to 414), and prior to theadjustment of each respective dynamic value (as described with referenceto 416).

At 412, the external price of the primary and/or secondary token isobtained by accessing the price oracle, for example, as described withreference to 208 of FIG. 2.

At 414, the updated total value of the primary token reserve and/or thesecondary token reserve is computed according to the external price ofthe primary and/or secondary tokens, for example, as described withreference to 210 of FIG. 2.

At 416, the dynamic weight for the primary token and/or the dynamicweight for the secondary token are adjusted according to the externalprice of the primary token and/or the secondary token, for example, asdescribed with reference to 212 of FIG. 2.

The descriptions of the various embodiments of the present inventionhave been presented for purposes of illustration, but are not intendedto be exhaustive or limited to the embodiments disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art without departing from the scope and spirit of the describedembodiments. The terminology used herein was chosen to best explain theprinciples of the embodiments, the practical application or technicalimprovement over technologies found in the marketplace, or to enableothers of ordinary skill in the art to understand the embodimentsdisclosed herein.

It is expected that during the life of a patent maturing from thisapplication many relevant cryptocurrencies will be developed and thescope of the term cryptocurrency is intended to include all such newtechnologies a priori.

As used herein the term “about” refers to ±10%.

The terms “comprises”, “comprising”, “includes”, “including”, “having”and their conjugates mean “including but not limited to”. This termencompasses the terms “consisting of” and “consisting essentially of”.

The phrase “consisting essentially of” means that the composition ormethod may include additional ingredients and/or steps, but only if theadditional ingredients and/or steps do not materially alter the basicand novel characteristics of the claimed composition or method.

As used herein, the singular form “a”, “an” and “the” include pluralreferences unless the context clearly dictates otherwise. For example,the term “a compound” or “at least one compound” may include a pluralityof compounds, including mixtures thereof.

The word “exemplary” is used herein to mean “serving as an example,instance or illustration”. Any embodiment described as “exemplary” isnot necessarily to be construed as preferred or advantageous over otherembodiments and/or to exclude the incorporation of features from otherembodiments.

The word “optionally” is used herein to mean “is provided in someembodiments and not provided in other embodiments”. Any particularembodiment of the invention may include a plurality of “optional”features unless such features conflict.

Throughout this application, various embodiments of this invention maybe presented in a range format. It should be understood that thedescription in range format is merely for convenience and brevity andshould not be construed as an inflexible limitation on the scope of theinvention. Accordingly, the description of a range should be consideredto have specifically disclosed all the possible subranges as well asindividual numerical values within that range. For example, descriptionof a range such as from 1 to 6 should be considered to have specificallydisclosed subranges such as from 1 to 3, from 1 to 4, from 1 to 5, from2 to 4, from 2 to 6, from 3 to 6 etc., as well as individual numberswithin that range, for example, 1, 2, 3, 4, 5, and 6. This appliesregardless of the breadth of the range.

Whenever a numerical range is indicated herein, it is meant to includeany cited numeral (fractional or integral) within the indicated range.The phrases “ranging/ranges between” a first indicate number and asecondary indicate number and “ranging/ranges from” a first indicatenumber “to” a secondary indicate number are used herein interchangeablyand are meant to include the first and secondary indicated numbers andall the fractional and integral numerals therebetween.

It is appreciated that certain features of the invention, which are, forclarity, described in the context of separate embodiments, may also beprovided in combination in a single embodiment. Conversely, variousfeatures of the invention, which are, for brevity, described in thecontext of a single embodiment, may also be provided separately or inany suitable subcombination or as suitable in any other describedembodiment of the invention. Certain features described in the contextof various embodiments are not to be considered essential features ofthose embodiments, unless the embodiment is inoperative without thoseelements.

Although the invention has been described in conjunction with specificembodiments thereof, it is evident that many alternatives, modificationsand variations will be apparent to those skilled in the art.Accordingly, it is intended to embrace all such alternatives,modifications and variations that fall within the spirit and broad scopeof the appended claims.

All publications, patents and patent applications mentioned in thisspecification are herein incorporated in their entirety by referenceinto the specification, to the same extent as if each individualpublication, patent or patent application was specifically andindividually indicated to be incorporated herein by reference. Inaddition, citation or identification of any reference in thisapplication shall not be construed as an admission that such referenceis available as prior art to the present invention. To the extent thatsection headings are used, they should not be construed as necessarilylimiting. In addition, any priority document(s) of this applicationis/are hereby incorporated herein by reference in its/their entirety.

What is claimed is:
 1. A computing device for cybersecurity of adistributed smart contract executing on a blockchain, comprising: atleast one hardware processor of a network connected server executing acode of the distributed smart contract of a distributed ledger dataset,the code for: managing a primary reserve of a plurality of primarytokens of a primary cryptocurrency and a secondary reserve of aplurality of secondary tokens of a secondary cryptocurrency; receiving atransaction request for the primary token; accessing a price oracle toobtain an external price of the primary token; computing an updatedtotal value of the primary reserve according to the external priceprovide by the price oracle; in response to the updated total value ofprimary reserve computed based on the price oracle being unequal to aninitial staked value of the primary reserve, adjust a primary dynamicreserve weight and adjust a secondary dynamic reserve weight, wherein atotal value computed by a function of the primary reserve after beingincreased or decreased by a target amount of primary tokens and usingthe adjusted primary and secondary dynamic reserve weights, is equal tothe initial staked value of the primary reserve, and the total value ofthe primary reserve is maintained at a predefined ratio to a total valueof the secondary reserve; and executing the transaction request.
 2. Thecomputing device of claim 1, wherein a primary dynamic reserve weight iscomputed using the parameters of: a total amount of primary tokens inthe primary reserve, a total amount of previously staked primary tokensin the primary reserve, a total amount of secondary tokens in thesecondary reserve, the external price of the primary token, and anexternal price of the secondary token, wherein a secondary dynamicreserve weight is computed by subtracting the primary dynamic reserveweight from 1, wherein a current value of the respective primary andsecondary token as offered by the smart contract is automaticallycomputed by the function using the amount of the respective primary andsecondary token in the respective primary and secondary reserve, amountof respective primary and secondary token in circulation, and therespective primary and secondary dynamic reserve weight.
 3. Thecomputing device of claim 1, wherein a current price of the primarytoken computed by the function using the adjusted weight and the primaryreserve, prior to being increased or decreased by the target amount ofprimary token, is different than the external price of the primary tokenprovided by the price oracle.
 4. The computing device of claim 1,wherein after execution of another transaction request for the targetamount of primary token corresponding to the increase or decrease of theprimary token, a current price of the primary token computed by thefunction using the adjusted weight and the primary reserve after beingincreased or decreased by the target amount, is equal to the externalprice of the primary token provided by the price oracle.
 5. Thecomputing device of claim 1, wherein after execution of anothertransaction request for the target amount of primary token correspondingto the increase or decrease of the primary token, the total value of theprimary reserve computed by the function using the adjusted weight andamount of the primary tokens stored in the primary reserve after beingincreased or decreased by the target amount, is equal to the initialstaked value of the primary reserve.
 6. The computing device of claim 5,wherein the target amount comprises the target amount of primary tokensthat are converted into the secondary token such that the predefinedratio of the price of the primary token relative to the price of thesecondary token computed by the function after the execution of theanother transaction request, becomes equal to the ratio of the price ofthe primary token relative to the price of the secondary token obtainedfrom the price oracle.
 7. The computing device of claim 1, furthercomprising code for: in response to the updated total value of theprimary reserve computed based on the price oracle being equal to theinitial staked value of the primary reserve, adjusting each respectivedynamic reserve weight to respective adjusted weights, wherein a totalvalue of the primary reserve computed by the function using therespective adjusted weights, is equal to the initial staked value of theprimary reserve, and the total value of the primary reserve ismaintained at a predefined ratio to a total value of the secondaryreserve.
 8. The computing device of claim 1, wherein the primary dynamicreserve weight and the secondary dynamic reserve weight are computedusing a Lambert W function.
 9. The computing device of claim 1, whereinthe primary dynamic reserve weight of the primary token is denoted as1/(1+x), and the secondary dynamic reserve weight of the secondary tokenis denoted as x/(1+x), wherein:$x = {\frac{T}{b\; p} \cdot {\sum\limits_{n = 1}^{\infty}\;{\frac{n^{n - 1}}{n!} \cdot \left( \frac{T\mspace{11mu}\log\mspace{11mu}\left( \frac{T}{t} \right)}{b\; p} \right)^{n - 1}}}}$T=primary token reserve staked balance, b=secondary token reservecurrent balance, p=ratio of primary token/secondary token off-chainprice as provided by the price oracle, t=secondary token reserve currentbalance as computed by the function.
 10. The computing device of claim1, further comprising code for: virtually amplifying the amount ofrespective primary and secondary tokens in the reserves, wherein thefunction is computed using the virtually amplified amount.
 11. Thecomputing device of claim 10, wherein: the virtually amplified amount ofeach respective token is computed by multiplying the initial stakedvalue of the respective token by an amplification value and subtractingtherefrom, a difference between the initial staked value of therespective token and the current balance of the respective token in thereserves.
 12. The computing device of claim 1, wherein the transactionrequest comprises one of: converting the primary token into thesecondary token, and converting the secondary token into the primarytoken, wherein the transaction request is executed after the adjustmentof each respective dynamic weight to the adjusted weight.
 13. Thecomputing device of claim 1, wherein the transaction request comprisesadding a deposit amount of a certain token to the reserves, wherein thetransaction request is executed prior to the accessing the price,computing to the updated value, and to the adjust each respectivedynamic value, and further comprising code for minting an amount of acertain pool token corresponding to the deposit amount of the certaintoken, wherein the value of the deposit amount of the certain token iscomputed using the function prior to the execution of the transactionrequest, wherein the certain token is the primary token or the secondarytoken, and the certain pool token is a primary pool token correspondingto the primary token or a secondary pool token corresponding to thesecondary token.
 14. The computing device of claim 13, wherein thetransaction requests comprises adding 100% of the deposit amount to thecertain token, and wherein the amount of the certain pool tokencorresponds to 100% of the deposit amount of the certain token.
 15. Thecomputing device of claim 13, wherein the transaction request comprisesadding a selected percentage deposit amount of a primary token andanother selected percentage deposit amount of the secondary token to thereserves, wherein the transaction request is executed prior to theaccessing the price, computing to the updated value, and to the adjusteach respective dynamic value, and wherein minting comprising minting aprimary amount of the primary pool token corresponding to the depositamount of the primary token, and minting a secondary amount of thesecondary pool token corresponding to the deposit amount of thesecondary token, wherein the value of the primary and secondary depositamounts is computed using the function prior to the execution of thetransaction request.
 16. The computing device of claim 13, wherein avalue of the certain pool token is constant before and after thetransaction request is executed, wherein a ratio between a total valueof the total amount of certain pool tokens and the initial staked valueof the certain token remains constant.
 17. The computing device of claim16, further comprising code for: extracting a fee in response toexecuting a conversion of the certain token, adding the fee to theinitial staked value of the certain token and/or the converted token,wherein the value of the certain pool token corresponding to the certaintoken is increased by the corresponding increase in the initial stakedvalue of the certain token.
 18. The computing device of claim 17,wherein extracting the fee comprises extracting a dynamic fee, whereinthe dynamic fee is reduced relative to a baseline fee when the totalvalue of the secondary reserve computed using an external price of thesecondary token is greater than the initial staked value of thesecondary reserve, and the dynamic fee is increased relative to thebaseline fee when the total value of the secondary reserve is less thanthe initial staked value of the secondary reserve, wherein the fee addedto the initial staked value is computed based on the baseline fee. 19.The computing device of claim 17, wherein extracting the fee comprisesextracting a dynamic fee, wherein the dynamic fee is computed when theconversion is from a primary token to a secondary token, wherein thedynamic fee is computed as:dynamic fee=baseline fee*secondary ratio,secondary ratio=staked amount of secondary tokens in the secondaryreserve/total amount of secondary tokens in the secondary reserve,wherein the fee added to the initial staked value is computed based onthe baseline fee.
 20. The computing device of claim 1, wherein thetransaction request comprises receiving an amount of certain pool tokensfor withdrawal, and further comprising code for: computing a withdrawalvalue of the certain token corresponding to the amount of certain pooltokens for withdrawal using the function prior to execution of thetransaction request; destroying the amount of certain pool tokens forwithdrawal; executing the transaction by removing the withdrawal valueof the certain token from the reserves, wherein the transaction requestis executed prior to the accessing the price, to computing the updatedvalue, and to adjust each respective dynamic value.
 21. The computingdevice of claim 1, further comprising code for: detecting a failure ofthe price oracle in providing the external price of the primary token;wherein executing the transaction request comprises executing thetransaction request using the function and dynamic reserve weights priorto the failure of the price oracle; detecting restoration of the priceoracle in providing the external price of the primary token; and inresponse to the updated total value of primary token computed based onthe restored price oracle and stored in the reserves being unequal tothe initial staked value of the primary token, adjust each respectivedynamic weight to an adjusted weight, wherein a total value computed bythe function using the adjusted weight, of the primary tokens stored inthe reserve after being increased or decreased by a target amount ofprimary tokens, is equal to the initial staked value.
 22. A method ofcybersecurity of a distributed smart contract executing on a blockchainusing at least one hardware processor of a network connected serverexecuting a code of the distributed smart contract of a distributedledger dataset, for: managing a primary reserve of a plurality ofprimary tokens of a primary cryptocurrency and a secondary reserve of aplurality of secondary tokens of a secondary cryptocurrency; receiving atransaction request for the primary token; accessing a price oracle toobtain an external price of the primary token; computing an updatedtotal value of the primary reserve according to the external priceprovide by the price oracle; in response to the updated total value ofprimary reserve computed based on the price oracle being unequal to aninitial staked value of the primary reserve, adjust a primary dynamicreserve weight and adjust a secondary dynamic reserve weight, wherein atotal value computed by a function of the primary reserve after beingincreased or decreased by a target amount of primary tokens and usingthe adjusted primary and secondary dynamic reserve weights, is equal tothe initial staked value of the primary reserve, and the total value ofthe primary reserve is maintained at a predefined ratio to a total valueof the secondary reserve; and executing the transaction request.
 23. Acomputer program product for cybersecurity of a distributed smartcontract executing on a blockchain, comprising: a non-transitory memorystoring thereon code for execution by at least one hardware process, thecode including instructions for: managing a primary reserve of aplurality of primary tokens of a primary cryptocurrency and a secondaryreserve of a plurality of secondary tokens of a secondarycryptocurrency; receiving a transaction request for the primary token;accessing a price oracle to obtain an external price of the primarytoken; computing an updated total value of the primary reserve accordingto the external price provide by the price oracle; in response to theupdated total value of primary reserve computed based on the priceoracle being unequal to an initial staked value of the primary reserve,adjust a primary dynamic reserve weight and adjust a secondary dynamicreserve weight, wherein a total value computed by a function of theprimary reserve after being increased or decreased by a target amount ofprimary tokens and using the adjusted primary and secondary dynamicreserve weights, is equal to the initial staked value of the primaryreserve, and the total value of the primary reserve is maintained at apredefined ratio to a total value of the secondary reserve; andexecuting the transaction request.